Add SVCB dohpath key #1359
Merged
Add SVCB dohpath key #1359
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The parameter is being added in [its own IETF draft][1] and also being used in the [IETF draft about Descovery of Designated Resolvers][2]. Additionally, the mappings of the numeric key values to strings are exported, under names consistent with the already existing exported mappings, to make it easier for the clients of the module to validate and print SVCB keys. Testing was done by sending SVCB queries for the "_dns.resolver.arpa" domain to OpenDNS's 146.112.41.2 server. [1]: https://datatracker.ietf.org/doc/html/draft-ietf-add-svcb-dns-02 [2]: https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-06.html
ainar-g
commented
Apr 11, 2022
miekg
reviewed
Apr 12, 2022
miekg
reviewed
Apr 12, 2022
miekg
reviewed
Apr 12, 2022
|
@miekg, thanks for the review, ptal! |
miekg
reviewed
Apr 12, 2022
miekg
reviewed
Apr 12, 2022
miekg
approved these changes
Apr 12, 2022
ainar-g
added a commit
to ainar-g/dns
that referenced
this pull request
Apr 12, 2022
The mappings of the numeric SVCB key values to strings are exported, under names consistent with the already existing exported mappings, to make it easier for the clients of the module to validate and print SVCB keys. Split off from miekg#1359.
Closed
|
I have to say I really dislike that we’re pulling in so many draft standards for SVCB. We’ve already seen them change in ways bordering on backwards-incompatible. I’d personally rather wait for these to be actually published as RFCs. |
|
I should clarify, I don’t object to implementing drafts where they can be kept as internal implementation details, but I do object when they become part of our public API. |
|
[ Quoting ***@***.***> in "Re: [miekg/dns] Add SVCB dohpath ke..." ]
I should clarify, I don’t object to implementing drafts where they can be kept
as internal implementation details, but I do object when they become part of
our public API.
I hear you. We should indeed be careful. OTOH this new RR has gained popularity quickly
and there seems to be some experimentation going on. Waiting for these I-Ds to be RFC can
take multiple years, so we should be a bit lenient here.
My position is: you know you're dealing with a pre-RFC RR here, so it's fine for us to
break things when the actual RFC turns out to be different.
(We could put such a warning in the code, but I don't think we have something prominent
enough where folks would actually read it)
|
|
@miekg, the Go standard library has a few spots where it explicitly says that something is experimental and is likely to change in the future. For example, package |
|
[ Quoting ***@***.***> in "Re: [miekg/dns] Add SVCB dohpath ke..." ]
***@***.***, the Go standard library has a few spots where it explicitly says that
something is experimental and is likely to change in the future. For example,
package syscall/js. I could send a PR where I go through all exported SVCB
identifiers and add a warning regarding the draft status of this functionality.
As ugly as that is, it might "solve" some of Tom's conerns (and mine - frankly)
|
aanm
pushed a commit
to cilium/dns
that referenced
this pull request
Jul 29, 2022
* Add SVCB dohpath key The parameter is being added in [its own IETF draft][1] and also being used in the [IETF draft about Descovery of Designated Resolvers][2]. Additionally, the mappings of the numeric key values to strings are exported, under names consistent with the already existing exported mappings, to make it easier for the clients of the module to validate and print SVCB keys. Testing was done by sending SVCB queries for the "_dns.resolver.arpa" domain to OpenDNS's 146.112.41.2 server. [1]: https://datatracker.ietf.org/doc/html/draft-ietf-add-svcb-dns-02 [2]: https://datatracker.ietf.org/doc/html/draft-ietf-add-ddr-06.html * Fix template length, docs; reverse some changes * Remove incorrect validations; improve docs
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The parameter is being added in its own IETF draft and also being used in
the IETF draft about Discovery of Designated Resolvers.
Additionally, the mappings of the numeric key values to strings are exported,
under names consistent with the already existing exported mappings, to make it
easier for the clients of the module to validate and print SVCB keys.
Testing was done by sending SVCB queries for the "_dns.resolver.arpa" domain to
OpenDNS's 146.112.41.2 server.